OLIVER (CICS interactive test/debug) was a proprietary testing and debugging toolkit for interactively testing programs designed to run on IBM's Customer Information Control System (CICS) on IBM's System/360/370/390 architecture.
| Developer(s) | Ken Dakin APT Ltd |
|---|---|
| Initial release | 1972 |
| Stable release | n/a / November 18, 1994 |
| Operating system | MVS, MVS/XA, MVS/ESA, DOS/VSE |
| Platform | IBM/360,370/390/ES9000 & later compatibles |
| Type | Debugger, Memory debugger, Hypervisor |
| License | Proprietary software |
| Website | n/a |
Contents |
OLIVER was written in 1972 by Ken Dakin, an independent CICS specialist (who also later produced SIMON (Batch Interactive test/debug), in response to a lack of suitable interactive debugging features in CICS. At the time, most CICS applications were written in IBM Basic assembly language and CICS had no features to prevent storage violations. As a result, errors in application programs frequently caused full CICS dumps and aborted the CICS session for all users. As more customers began using both COBOL and PL/I applications, the software supported these both at the assembly level and at source level from information collected at compile time.
OLIVER provided source and instruction level Program animation, instruction step ("single cycle"), conditional program breakpoint ("Pause") and storage alteration features for Assembler, COBOL and PL/I programs. High level language (HLL) users were able to see and modify variables directly at a breakpoint.
From the earliest version, OLIVER was a "full screen" debugger, incorporating a mult-line symbolic disassembler allowing program animation. Line commands provided allowed a pause/breakpoint to be set anywhere in the displayed program with a single keystroke. Registers were all displayed continuously (and automatically highlighted if any changes occurred). A "hyperlink-style" feature allowed memory to be displayed using an "L" (meaning load) line command in any register or other fullword memory display.
Oliver also provided fully automatic features to prevent application program errors such as:-
It was possible to correct many errors and interactively alter the control flow of the executing application program while still running. This permitted more errors to be detected for each compilation (which, at the time, were often scheduled batch jobs with printed output, often requiring several hours "turnaround", before eventually re-loading the program (using CSMT/CEMT Newcopy) and retrying the failing transaction).
Whatever kind of program error was encountered, OLIVER always discovered it before actual execution took place and always (up to) the last 84 previous instruction locations were immediately available to diagnose the precise path leading to the specific error (true across linked modules of possibly mixed languages, dynamically loaded programs or even dynamically built runtime code). In the case of potential loops, it was possible to re-try until the next threshold was reached.
OLIVER additionally provided fully automatic storage protection features to prevent rogue applications from overwriting storage occupied by other applications ("storage violations", or buffer overflows), OLIVER included complete and automatic protection for CICS system tables and all other otherwise unprotected kernel code.
OLIVER was an instruction set simulator that provided all functions through full simulation of the object code that was under total control of the OLIVER monitoring & execution engine (a form of 'type 2' hypervisor or virtual machine). OLIVER made extensive use of control tables in the execution engine to "reverse engineer" the target programs machine code to generate alternative, but fully protected, simulation code.
The simulation was deliberately limited to CICS application code and EXEC interface code (not the CICS kernel or operating system or hardware), including full instruction trace if required at machine code level. Oliver provided instruction path length metrics at any point during execution, providing a means {Performance analysis} to perform program optimization, that was important for time sensitive on-line transactions.
OLIVER was fully quasi-reentrant, allowing application programs to be "paused" at different breakpoints by multiple users simultaneously and was entirely "non-invasive" to the targeted application's object code (i.e. did not modify the run time program memory to provide breakpoints). This technique allowed later hardware protected CICS application program's to be monitored with essentially no change to the OLIVER kernel code - unlike many of its competitors - which had used invasive techniques which would no longer work for these programs because of the operating system program protection.
It was also possible to halt execution according to the state of memory or registers, enabling more targeted break-points (than simply pausing before a particular instruction every time it is executed).
Examples: Pause if -
| program name | display "program" (source or dissassembly) |
|---|---|
| (line command) "P" | Pause at this line (before execution) |
| (line command) "H" | hold display of this associated data line (watch) |
| "-" | show dissassembled program |
| "+" | show source program |
| (3270) PA1 key | execute single stmt/instruction |
| (line command) "L" | display memory at this address (hyperlink) |
| "Stmt" | switch to statement animation |
| "trace" | provide full instruction trace to CSSL TD queue |